🛠️ AI Studio × Vibe Coding 30 天：技術大會痛點擊破百寶箱
5 大分類 × 6 大情境，共 30 天，且每天都是「獨立」的微型實作（不具連貫性）。
這樣的安排超級聰明！它就像是一個「技術大會的百寶箱」，讀者每一天都可以隨插隨用，學習一個全新的 AI Studio 溝通技巧，並帶走一個實用的 Vibe Coding 腳本。
⚡ 第二週：AI for Engineering (研發與工程創新)
| 欄位 | 內容設計 |
|---|---|
| 分類 | 研發與工程創新 (AI for Engineering) |
| 情境標題 | Day 11: 伺服器崩潰急救箱：百萬行 Log 揪出 N+1 慢查詢與效能優化 (沉默殺手版) |
| 問題描述 | 伺服器沒有亮紅燈報錯，但網頁轉半天就是打不開。面對毫無明顯 Error 的海量資料庫查詢 Log，工程師很難用肉眼揪出拖慢效能的「沉默殺手」（如 ORM 造成的 N+1 Query 慢查詢）。 |
| 應用程式任務 | 讓 AI 讀取雜亂的 API 請求日誌與連續的 SQL 執行時間紀錄，精準定位出 N+1 查詢瓶頸，並直接給出框架層級的重構建議碼（如 Eager Loading）與快取策略。 |
| 提示／關鍵功能點 | 角色設定為資深 SRE 效能優化專家 / 關聯性日誌分析 (Log Correlation) / N+1 查詢診斷 / 架構重構與緩存策略 (Caching Strategy)。 |
| 完整提示詞範例 | 「你現在是一位專精效能調優的資深 SRE。這是一段大會報名系統首頁載入時的雜亂 Log，裡面夾雜了 API 請求以及一堆連續且極度相似的 SQL 查詢紀錄。請幫我完成以下效能診斷：1. 【瓶頸定位】：在海量 Log 中揪出拖慢全站速度的『沉默殺手』，具體指出是哪一張資料表或哪一段業務邏輯引發了 N+1 Query 問題。2. 【根因白話文】：用淺顯易懂的白話文，向非技術背景的 PM 解釋為什麼這種查詢模式會造成嚴重的效能災難。3. 【解藥開立】：請給出具體的重構建議程式碼（示範如何改用 Eager Loading 來合併查詢），並評估是否需要加入 Redis 快取機制來徹底根除延遲。」 |
iThome鐵人賽
看影片追技術